compiletest: Support optional error annotations #140586
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
that are not required to annotate an actual error, which is sometimes useful for target-dependent errors. The syntax is `//~ ERROR? message`.
rustbot
added
A-compiletest
|
The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes. cc @BoxyUwU, @jieyouxu, @Kobzol Some changes occurred in src/tools/compiletest cc @jieyouxu |
|
I'm hesitant to support optional error annotations in this fashion (as opposed to not requiring exhaustive error annotations with an explicit opt-in), for a few reasons:
I'm playing around w/ point (3) in #140588. Let me get back to you after playing around with the example tests changed in this PR. |
|
Okay, I agree it's easy to misuse and some of the cases should be fixed in the compiler (especially We just need to not forget to remove the FIXMEs if that doesn't work out. |
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
May 4, 2025
Adjust some ui tests re. target-dependent errors Alternatives to optional error annotations in rust-lang#140586: - Continue to ignore target-dependent additional errors in `tests/ui/panic-runtime/{two-panic-runtimes.rs,tests/ui/panic-runtime/want-abort-got-unwind.rs,tests/ui/panic-runtime/want-abort-got-unwind2.rs}` -- but explain why some targets have more errors than others. - Use `-Cpanic=abort` for `tests/ui/cfg/cfg_false_no_std-2.rs`. In that test, the panic strategy does not matter w.r.t. test intention. - Adjust FIXMEs in `tests/ui/debuginfo/debuginfo-type-name-layout-ice-94961-2.rs` to track it in rust-lang#140620. --- try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: aarch64-apple try-job: x86_64-apple-1
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 4, 2025
Rollup merge of rust-lang#140588 - jieyouxu:opt-error, r=petrochenkov Adjust some ui tests re. target-dependent errors Alternatives to optional error annotations in rust-lang#140586: - Continue to ignore target-dependent additional errors in `tests/ui/panic-runtime/{two-panic-runtimes.rs,tests/ui/panic-runtime/want-abort-got-unwind.rs,tests/ui/panic-runtime/want-abort-got-unwind2.rs}` -- but explain why some targets have more errors than others. - Use `-Cpanic=abort` for `tests/ui/cfg/cfg_false_no_std-2.rs`. In that test, the panic strategy does not matter w.r.t. test intention. - Adjust FIXMEs in `tests/ui/debuginfo/debuginfo-type-name-layout-ice-94961-2.rs` to track it in rust-lang#140620. --- try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: aarch64-apple try-job: x86_64-apple-1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
that are not required to annotate an actual error, which is sometimes useful for target-dependent errors.
The syntax is
//~ ERROR? message.This is sort of a low cost low benefit feature, that is useful in specific cases.
I think it's better to have it, but not having it would also be ok.
The specific syntax is also up to debate.
r? @jieyouxu